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(57) Abstract: The invention concerns a method for loading an applet in a smart card (2a), using two loading programmes, a so-called 
In- loader (TL), stored in the card, and Off-loader, respectively. The invention is characterised in that two specific communication 
protocol layers are provided, one in a terminal (1) hosting the card reader, the other in the card. Said layers include in particular 
intelligent agents enabling the card to provide a WEB client/server and a CGI gateway functional capability. The method comprises 
at least one step during which a HTTP request is sent to the card, to address a HTML page, a step which consists in retrieving pa- 
rameterising data transported by a HTML form and a step which consists in executing a second loading programme (IL) using the 
CGI functional capability to load the applet. 

(57) Abrege : L' invention concerne le chargement d'une "applet" dans une carte a puce (2a), a Paide de deux programmes de char- 
gement, dits "In-loader" (DL), stock6 dans ia carte, et "Off-loader" (OL), respectivement. Selon Pinvention, on prcvoit deux couches 
protocolaires de communication spe'cifiques, Tune dans un terminal (1) hebergeant le lecteur de la carte, Pautre dans la carte. Ccs 
couches comprennent notamment des agents intelligents permettant a la carte d*offrir une fonctionnalite* de client/serveur "WEB" et 
de passerelle "CGI". Le proc£d6 comprend au moins une 6tape pendant laquelle une requete "HTTP" est envoyee a la carte, pour 
adresser une page "HTML", une 6iape de recuperation dc donnees de parame*trage v£hiculees par un formulaire "HTML" et une 
etape d'execution du second programme de chargement (IL), par mise en oeuvre de la fonctionnalite "CGI", pour charge Y "Applet". 
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En ce qui concerne les codes a deux lettres et autres abrevia- 
tions, se re'fe'rer aux "Notes explicatives relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCT. 
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PROCEDE DE CHARGEMENT D*UNE PIECE DE LOGICIEL DANS UNE 
CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET" 



L'invention concerne un procede de chargement d'une piece de 
logiciel dans une carte a puce. 

Elle s'applique plus particulierement au chargement d'une piece de 
5 logiciel appelee en frangais "appliquetfe", plus connue sous le terme anglo- 
saxon d* "applet". II s'agit d'une application ecrite en langage "JAVA" 
(marque deposee). Ces applications, generalement peu volumineuses, sont 
independantes des architectures des systemes sur lesquelles elles sont 
implantees. Elles peuvent done fonctionner sur n'importe quel systeme 
10 informatique, dans la mesure ou celui-ci implemente le concept dit de 
"machine virtuelle JAVA" ("Java Virtual Machine"). Une application ecrite en 
langage JAVA est en general traduite en un langage intermediate dit "Byte 
Code". La machine virtuelle JAVA precitee constitue un interpretateur de ce 
"Byte Code", de maniere a etre executee directement sur un systeme cible, 
15 hote de ladite machine virtuelle. 

Generalement, les architectures de systeme sur lesquelles tourne 
ce type d'applications sont du type dit client-serveur. Dans ce cas, on parle 
egalement de "servlet" pour une application stockee sur un systeme serveur 
et "applet" pour une application stockee sur un systeme client. Dans ce qui 
20 suit, on utilisera le terme "applet" de fagon generique. 

Des pieces de logiciel, se presentant sous la forme d 1 "applet" qui 
vient d'etre rappelee, dans la mesure ou la quantite de code n'est pas trop 
volumineuse, peuvent etre stockees dans une memoire non volatile presente 
sur une carte a puce, au meme titre que toute autre application. 
25 Aussi, le procede selon I'invention est plus particulierement 

concerne par un terminal ou station d'utilisateur muni d'un lecteur de carte a 
"puce". 
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Dans le cadre de rinvention, le terme "terminal" doit etre compris 
dans un sens general. Le terminal precite peut etre nofamment constitue par 
un ordinateur personnel fonctionnant sous divers systemes d'exploitation, 
tels WINDOWS ou UNIX (tous deux etant des marques depos§es). II peut 
5 etre aussi constitue par une station de travail, un ordinateur portable ou un 
terminal de carte dit dedte. 

_ _ _ _ Dans Ketatactuel de-la technique,Je chargementd!une_"applet" sur 

une carte a puce (encore appele telechargement) se fait grace a deux 
programmes specifiques. Ces programmes sont generalement connus sous 

10 les termes anglo-saxons "Off- Loader", pour le premier, et "In-Loader", pour 
le second. Le programme "Off-Loader" s'execute sur le terminal et le 
programme "In-Loader" s'execute dans la carte a puce. Les programmes de 
chargement "Off-Loader" et "In-Loader" communiquent entre eux au travers 
d'une liaison normalisee de type ISO 7816-3, protocole universellement 

15 retenu pour les communications entre une carte a puce et son terminal hote. 
Ce protocole met en ceuvre une suite d'echanges generalement 
proprietaires (commandes d'un type dit "APDU" qui seront explicitees ci- 
apres) afin de realiser le chargement d'une "applet". 

La figure 1A annexee a la presente description illustre de fagon 

20 schematique Tarchitecture mise en oeuvre pour le chargement d f "applets" 
dans une carte a puce selon Tart connu. 

Le terminal 1 stocke un premier programme specifique de 
chargement ("Off-Loader"), reference OL. II communique avec une carte a 
puce 2, via un lecteur de carte a puce 3. Les transmissions s'effectuent selon 

25 un protocole de communication normalise, faisant appel aux commandes 
precitees, protocole qui sera detaille ci-apres. 

La carte a puce 2, pour sa part stocke un second programme 
specifique de chargement ("In-Loader"), reference IL. 

Un premier inconvenient de ce procede est que les programmes IL 

30 et OL doivent etre apparies pour pouvoir communiquer entre eux. II s'ensuit 
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que s'ils sont d'origines differentes, ils ne sont pas, a priori, compatibles. 
Cette caracteristique est liee au jeu de commandes a utiliser. 

Un deuxieme inconvenient est du au fait que les communications 

s'effectuentselon1el)~^ 

5 proximite physique entre les programmes OL et IL. II s'ensuit que le 
programme OL doit generalement s'executer directement sur le terminal 1 et 

non, par exemple, sur un autre terminal^ou un_seryeuLeloigne _ 

Or, avec I'essor spectaculaire du reseau Internet, un nombre 
toujours croissant de terminaux sont connectes a ce reseau, notamment 
w pour pouvoir etre en liaison avec des serveurs eloignes, de type "WEB". II 
serait done interessant, par exemple, de pouvoir stocker la partie "Off- 
Loader" OL des programmes de chargement d' "applets" sur un serveur 
"WEB" connecte a ce reseau. Les "applets" a charger sur une ou plusieurs 
carte(s) a puce pourraient d'ailleurs etre aussi stockees sur ce serveur ou 
15 sur un ou plusieurs autres serveurs de ce type. 

Dans I'etat actuel de la technique, ce mode operatoire bute sur une 
double impossibilite. La premiere a deja ete evoquee : la norme retenue pour 
les communications entre le terminal et la carte a puce impose a priori une 
proximite physique entre la localisation des programmes "Off-Loader", OL, et 
20 "In-Loader", IL. 

D^utre part, les transmissions entre deux systemes, par exemple 
un terminal et un serveur eloigne, via le reseau Internet, font appel a des 
protocoles de type Internet. Dans Tetat actuel de la technique, il n'est pas 
possible de realiser des communications directes entre une carte a puce et 
25 le reseau Internet, comme il va Petre explicite egalement. 

Dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers 
I'exterieur, du type dit "extranet", et de fa?on generate tout reseau dans 
30 lequel les echanges de donnees s'effectuent selon un protocole du type 
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Internet. Dans ce qui suit un tel reseau sera appele de fagon generique 
"reseau Internet". 

On va tout d'abord rappeler brievement Tarchitecture generate d'un 



systeme d'applicatioh a base de carte a puce, relie a un reseau Internet, par 
5 reference aux figures 1 B et 1 C. 

Un systeme d'application a base de carte a puce comporte 

--generalementles-elements principaux.suivants .: 

une carte a puce ; 

un systeme hote constituant le terminal precite ; 
10 - un reseau de communication, a savoir le reseau Internet dans 

('application preferee ; 

et un serveur d'application connecte au reseau Internet. 
La figure 1B illustre schematiquement un exemple d'architecture de 
ce type. Le terminal 1, par exemple un ordinateur individuel, comporte un 
15 lecteur 3 de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement 
integre dans le terminal 1. La carte a puce 2 comporte un circuit integre 20 
dont des connexions d'entrees-sorties affleurent en surface de son support 
pour autoriser une alimentation en energie electrique et des communications 
avec le terminal 1. Ce dernier comprend des circuits d'acces 11 au reseau 
20 Internet Rl. Ces circuits peuvent etre constitues par un modem pour se 
connecter a une ligne telephonique commutee ou a une voie de 
communication a plus haut debit : reseau numerique a integration de 
services ( n RNIS M ), cable ou liaisons par satellite, etc. Les circuits 11 
permettent de se connecter au reseau Internet Ff/, directement ou via un 
25 prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). On peut egalement avoir recours a un systeme 
intermediaire tel qu'un "proxy" ou un systeme d'isolation dit "firewall" ("pare- 
feu" ou encore appele "garde barriere"). 

Le terminal 1 comprend naturellement tous les circuits et organes 
30 necessaires a son bon fonctionnement, et qui n'ont pas ete represents 
dans un but de simplification du dessin : unite centrale, memoires vive et 
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fixe, memoire de masse a disque magnetique, lecteur de disquette et/ou de 

i 

CedeRom, etc. 

Habituellement, le terminal 1 est aussi relie a des peripheriques 
classiques, integres ou non, tels un ecran de visualisation 5, un clavier 6a et 
5 une souris 6b, etc. 

Le terminal 1 peut etre mis en communication avec des serveurs ou 

tous systemes informatiques connectes au reseau Rl, dont un seul,_4, est. 

illustre sur la figure 1A. Les circuits d'acces 11 mettent le terminal 1 en 
communication avec les serveurs 4 grace a un logiciel particulier 10, appele 
10 navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- 
ci permet d'acceder a diverses applications ou fichiers de donnees repartis 
sur ('ensemble du reseau Rl, generalement selon un mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocols repondant a des standards comprenant 
is plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de 
type Internet, les communications s'effectuent selon des protocoles 
specifiques a ce type de communications, qui seront detailles ci-apres, mais 
qui comprennent egalement plusieurs couches logicielles. Le protocole de 
communication est choisi en fonction de 1'application plus particulierement 
20 visee : interrogation de pages "WEB", transferts de fichiers, courrier 
electronique (e-mel, ou "e-mail" seion la terminologie anglo-saxonne), 
forums ou "news", etc. 

L'architecture logique du systeme comprenant un terminal, un 
lecteur de carte a puce et une carte a puce, est representee 
25 schematiquement par la figure 1C. Elle est decrite par la norme ISO 7816, 
qui elle-meme component plusieurs sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le 
marquage des cartes ; 

ISO 7816-3, en ce qui concerne le transfert de donnees entre 
30 le terminal et la carte a puce ; et 
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ISO 7816-4, en ce qui concerne la structure du jeu cTordres et 
le format des commandes. 

Sur la figure 1C, du cote terminal 1, on n*a represents que les 
— — couches-repondantH ana~norme ISO 7816-3, referencees 101, et un 
5 gestionnaire d'ordres "APDU" (norme ISO 7816-4), reference 102. Du cote 
carte a puce 2, les couches repondant a la norme ISO 7816-3 sont 
referencees 200 et Je gestionnaire d'ordres ."ADEU H _( norme -ISO-781 6-4) est 
reference 201 . Les applications sont referencees >4i , A t \ A n ; n etant le 
nombre maximum ^'applications presentes sur la carte a puce 2. 

10 Une application, Aj, presente dans la carte a puce 2, dialogue avec 

le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente typiquement des 
ordres d'ecriture et des ordres de lecture. Le format des ordres est connu 
sous I'abreviation anglo-saxonne de "APDU" (pour "Application Protocol 
Data Unit"). II est defini par la norme ISO 7816-4 precitee. Une "APDU" de 

15 commande est notee "APDU.commancT et une "APDU" de reponse est 
notee "APDU.response". Les "APDU" sont echangees entre le lecteur de 
carte et la carte a puce au moyen d'un protocole specifie par la norme ISO 
7816-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

20 Lorsque la carte a puce 2 inclut plusieurs applications distinctes, 

comme illustre sur la figure 1C, on parle de carte multi-applicative. 
Cependant, le terminal 1 ne dialogue qu'avec une seule application a la fois. 
Une application Aj se presente, par exemple, sous la forme d'une "applet" 
qui peut etre enregistree initialement, ou encore chargee a partir du terminal 

25 1. Pour ce faire, comme illustre par la figure 1A, on a recours a un 
programme "Off- Loader", OL, enregistre dans le terminal 1 et a un 
programme "In-Loader", IL, qui forme Tune des applications Aj de la carte a 
puce 2. 

La selection d'une application particuliere Aj est obtenue a I'aide 
30 d'une "APDU" du type selection ("SELECT"). Une fois ce choix effectue, les 
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"APDU" qui le suivent sont achemines vers cette application. Une "APDU 
SELECT" nouvelle a pour eflet d'abandonner ('application en cours et d'en 
choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 
permet^ecRbisirlJhe application particuliere A\ dans la carte a puce 2, de 
5 memoriser I'application ainsi choisie, et de transmettre et/ou recevoir des 
"APDU" vers et depuis cette application. 

En_ resume_de ce _qui_ vient d'etre -decrit r -la- selection- d'une 

application A\ et le dialogue avec celle-ci s'effectuent par echanges d'ordres 
"APDU". On suppose que les applications A\ sont des applications 

w conventionnelles, que Ton appellera ci-apres "GCA" (pour "Generic Card 
Application" ou application de carte generique). 

Ce mode operatoire explique que les programmes OL et IL doivent 
etre apparies, pour que les ordres "APDU" echanges puissent etre 
compatibles et compris par ces deux applications. 

15 Ces rappels etant effectues, il est a noter que la carte a puce 2 ne 

peut communiquer directement avec les navigateurs standards du 
commerce, sauf a modifier le code de ces derniers. 

En outre, et surtout, les cartes a puce actuelles, qui par ailleurs sont 
conformes aux standards et normes rappeles ci-dessus, ont une 

20 configuration materielle et logicielle qui ne permet pas non plus de 
communiquer directement avec le reseau Internet. En particulier, elles ne 
peuvent recevoir et transmettre des paquets de donnees, selon Tun ou 
Tautre des protocoles utilises sur ce type de reseau. II est done necessaire 
de prevoir une piece de logiciel additionnelle, implantee dans le terminal 1 , 

25 generalement sous la forme de ce qui est appele un "plug-in", selon la 
terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 12 
sur la figure 1B, effectue I'interface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 
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L'invention vise a pallier les inconvenients des procedes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles, tout en 
repondant aux besoins qui se font sentir. 

Selon une premiere caracteristique de l'invention, les deux 
5 programmes de chargement, OL et IL ne sont plus dependants Pun de 
I'autre. En d'autres termes, ils n'ont plus a etre apparies pour etre 

- compatibles.- - 

Selon une deuxieme caracteristique de ['invention, la partie OL des 
programmes de chargement n'a plus a etre stockee obligatoirement dans le 
10 terminal, c'est-a-dire en relation de proximite physique avec la seconde 
partie IL. Tout au contraire, le programme OL peut etre stocke sur un 
serveur eloigne, connecte au terminal via un reseau de type Internet. 

Pour ce taire, et selon une autre caracteristique de l'invention, la 
carte a puce se comporte comme un serveur/client de type "WEB" pour le 
15 terminal qui lui est associe. 

Pour atteindre ce but, on prevoit une couche de logiciel de 
communication specifique dans la carte a puce et son pendant dans le 
terminal. Le terme "specifique" doit etre entendu comme specifique au 
procede de l'invention. En effet, ces couches de communications, dites 
20 specifiques, sont banalisees quelle que soit Tapplication consideree. Elles 
n'interviennent que dans le processus d'echanges de donnees 
bidirectionnels entre la carte a puce et le terminal, d'une part, et la carte a 
puce et le reseau, d'autre part. 

Les couches logicielles de communication specifiques comprennent 
25 notamment des composants logicieis, dits "agents intelligents", permettant 
en particulier des conversions de protocoles. Les agents intelligents seront 
appeles ci-apres plus simplement "agents". II existe des agents appareilles 
dans les couches de communication specifiques respectives associees au 
terminal et a la carte a puce. Selon le procede de l'invention, il s'etablit des 
30 sessions entre agents appareilles. 
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Selon une au:re caracteristique, le procede de I'invention rend 
possible I'activation duplications de type conventionnel, c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir les modifier en 
quoi que ce soit" ~ 
5 Pour ce faire, on prevoit un ou plusieurs agents intelligents 

particuliers dits traducteurs de script, qui regoivent des requetes d'un 
navigateur et^ les traduisent en ordres "APDU" comprehensibles par 
1'application de type "CGA". De ce fait, on implante dans la carte a puce une 
tonction similaire a celle connue par ailleurs sous la denomination "CGI" 
w dans les serveurs "WEB" classiques. Cette fonction permet de mettre en 
oeuvre une application dans la carte a puce par un protocole Internet de type 
"HTTP". 

Le chargement d'une "applet" dans la carte a puce peut s'effectuer 
par cette interface "CGI". La partie IL du programme de chargement est 

15 considere comme etant un script de commandes, que Ton appellera "cgi- 
script", attache a la fonctionnalite serveur "WEB" offerte par la carte a puce. 
Les echanges entre les programmes OL et IL peuvent se derouler avec 
Taide de formulaires classiques en langage "HTML" ou "forms" selon la 
terminologie anglo-saxonne. 

20 Tout en conservant les normes ISO precitees pour les 

communications entre terminal et carte a puce, via le lecteur de carte a 
puce, le procede selon I'invention permet des echanges entre les parties de 
programmes de chargement OL et IL en faisant appel au protocole de 
communication Internet "TCP/IP", la partie OL et les "applets" a charger 

25 pouvant etre stockees en local ou dans un serveur eloigne. 

L'invention a done pour objet principal un procede de chargement 
d'une piece de logiciel dans une carte a puce a partir d'un terminal connecte 
a ladite carte a puce par I'intermediaire d'un lecteur de carte a puce 
permettant des communications selon un premier protocole determine, ledit 
30 chargement s'effectuant par la mise en oeuvre et la cooperation de premier 
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et second programmes de chargement, ledit second programme de 
chargement etant stocke dans ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans 
5 ladite carte a puce, une premiere piece de logiciel, formant une couche 

protocolaire de communication specifique ; 
_ _ _ _ _b/ - -une deuxieme phase preliminaire- consistant- a- implanter r dans- - — 
ledit terminal, une seconde piece de logiciel, formant une couche 
protocolaire de communication specifique ; 
10 en ce que lesdites premiere et seconde pieces de logiciel comprennent 

en outre au moins une paire de premieres entites logicielles appariees, 
chacune desdites entites cooperant rune avec I'autre de maniere a 
permettre I'etablissement d'une session d'echanges de donnees 
bidirectionnels entre au moins ledit terminal et ladite carte a puce, de 
15 maniere a ce que ladite carte a puce offre la fonctionnalite d'un client/serveur 
"WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce au moins une deuxieme entite logicielle, 
apte a interpreter une suite destructions et a la traduire en une suite 
20 d'ordres, de maniere a cooperer avec ladite seconde piece de logiciel 
specifique pour que ladite carte a puce offre une fonctionnalite d'interface 
passerelle dite "CGI", la dite carte a puce comprenant au moins une desdites 
suites destructions associee au dit second programme de chargement ; 
et en ce qu'il comprend au moins les etapes suivantes : 
25 1/ ouverture d'une premiere session d'echanges de donnees 

entre au moins ledit terminal et ladite carte a puce, pour la transmission 
d'une requete pour que ledit premier programme de chargement 
recupere des donnees de parametrage de chargement fournies par 
ledit second programme de chargement ; 
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21 ouverture d'une deuxieme session d'echanges de donnees 

entre ladite carte a puce et au moins ledit terminal pour trarismettre 
iesdites donnees de parametrage de chargement au dit premier 
— programme de chargement; — Iesdites - donnees — de — parametrage- 
5 comportant une reference aux dites instructions associees au dit 

second programme de chargement ; et 

3/ ouverture d'une troisieme session d'echanges de donnees 
entre au moins ledit terminal et ladite carte a puce, pour la soumission d'un 
fichier de chargement prenant en compte Iesdites donnees de parametrage 
10 de chargement, ledit fichier comprenant des donnees representant ladite 
piece de logiciel a charger; interpretation de ladite suite destructions 
associee au dit second programme de chargement, par mise en oeuvre de 
ladite fonctionnalite "CGI", de maniere generer une suite d'ordres transmise 
au dit second programme de chargement, a executer ce programme et a 
15 obtenir ledit dechargement de ladite piece de logiciel. 

L'invention va maintenant etre decrite de fagon plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1A illustre sch§matiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
20 carte a puce selon Tart connu ; 

les figures 1B et 1C illustrent les architectures materielle et 
logique, respectivement, d'un exemple de systeme d'application a 
base de carte a puce connecte a un reseau Internet selon Tart 
connu, ; 

25 - la figure 2 illustre schematiquement un exemple de systeme 

d'application a base de carte a puce selon l'invention, cette derniere 
agissant en tant que client/serveur "WEB" ; 

la figure 3 est un diagramme d'etats d'une session entre des 
entites logicielles dites agents intelligents, selon un aspect de 

30 ['invention ; 
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la figure 4 illustre de fagon simplifiee ['architecture logique d'un 
systeme selon invention dans tequel la carte a puce comprend des 
agents intelligents ; 

la figure 5 illustre de fagon simplifiee I'architecture logique d'un~ 
systeme selon I'invention dans lesquels la carte a puce comprend 
des agents intelligents traducteurs de scripts ; 
- ----- la figure 6 illustre-schematiquemenUun-exemple.de_reaiisation _ 

d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon 1'invention ; 

- la figure 7 illustre la structure d'un fichier de chargement d'une 

"applet" pouvant etre en oeuvre par le procede selon I'invention ; 

la figure 8 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 

un premier exemple de realisation pratique ; 

la figure 9 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 

un deuxieme exemple de realisation pratique ; 

les figures 9 et 10 illustrent deux exemples de formulaires en 

langage "HTML" utilisables par le procede de chargement d'une 

"applet" dans une carte a puce selon I'invention, pour la mise en 

oeuvre des methodes dites "GET" et "POST", respectivement ; et 
les figures 12A a 12G illustrent plusieurs variantes de 

realisation de realisation d'architectures de systemes permettant le 

chargement d'une "applet" dans une carte a puce selon I'invention. 

Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 
placera ci-apres dans le cadre de I'application preferee de I'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un terminal connecte a un ou 
plusieurs serveurs eloignes via le reseau Internet. 

Avant de decrire le procede d'activation duplications localisees 
dans une carte a puce selon I'invention et de detainer une architecture pour 
sa mise en oeuvre, par reference a la figure 2, il apparait tout d'abord utile de 
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rappeler brievement les caracteristiques principales des protocoles de 
communication sur les reseaux. 

L'architecture des reseaux de communication est decrite par 

diverses~couchesr^ A-titre~d'exempIe— le~standard~ M OSr t- ("Op"e"n~SysTeTn 

5 Interconnection"), defini par I' "ISO", comporte sept couches qui vont des 
couches dites basses (par exemple la couche dite "physique" qui concerne 
le support de transmission physique) aux couches dites hautes (par exemple 
la couche dite "d'application"), en passant par des couches intermediates, 
notamment la couche dite de "transport". Une couche donnee offre ses 

w services a la couche qui lui est immediatement superieure et requiert de la 
couche qui lui immediatement inferieure d'autres services, via des interfaces 
appropriees. Les couches communiquent a I'aide de primitives. Elles 
peuvent egalement communiquer avec des couches de meme niveau. Dans 
certaines architectures, plusieurs couches peuvent etre inexistantes. 

15 Dans un environnement de type Internet, les couches sont au 

nombre de cinq, et de fagon plus precise, en allant de la couche superieure 
a la couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", 
etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de 
reseau ("IP"), la couche dite de liens de donnees ("PPP", "Slip", etc.) et la 

20 couche dite physique. 

Si on se reporte de nouveau a la figure 2, a I'exception de couches 
logicielles de protocole de communication specif iques, referencees 13 et 
23a, respectivement implantees dans le terminal 1 et la carte a puce 2a, les 
autres elements, materiels ou logiciels, sont communs a Tart connu, et il n f y 

25 a pas lieu de les re-decrire de fagon detaillee. 

Le terminal 1 comprend des circuits 11 d'acces au reseau Rl, 
constitues par exemple d'un modem. Ces circuits regroupent les couches 
logicielles inferieures, Ci et C2, qui correspondent aux couches "physique" 
et de "lien de donnees". 
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On a egalement represents les couches superieures, C3 et C4, qui 
correspondent aux couches "d'adressage de reseau" ("IP", dans le cas 
d'lnternet) et de "transport" ("TCP"). La couche superieure d'application 

5 ^interface entre les couches inferieures, C1 et C2, et les couches 

superieures, C3 et C4, est constitute par une couche logicielle 
- - generalement appelee-driver couches-basses".- Les couches superieures, - 
C3 et C4, s'appuient sur cette interface et sont rnises en ceuvre par 
Tintermediaire de bibliotheques de fonctions specifiques ou bibliotheques 
10 reseau 14, avec lesquelles elles correspondent. Dans le cas du reseau 
Internet, "TCP/IP" est mis en oeuvre au moyen de bibliotheques dites de 
"sockets". 

Cette organisation permet a un navigateur 1 0 de poser des requetes 
vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), 

15 pour le transfert de fichiers (protocole "FTP") ou renvoi de courrier 
electronique (protocole "e-mail"), ce de fagon tout a fait classique en soL 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou 
non. Pour communiquer avec la carte a puce 2a, le lecteur de carte 30 
englobe egalement deux couches basses, CC1 (couche physique) et CC2 

20 (couche de lien de donnees), jouant un role similaire aux couches C1 et C2. 
Les interfaces logicielles avec les couches CC1 et CC2 sont decrites, par 
exemple, par la specification "PC/SC" ("part 6, service provider"). Les 
couches elles-memes, CC1 et CC2, sont notamment decrites par les normes 
ISO 7816-1 a 7816-4, comme il a ete rappele. 

25 Une couche logicielle supplemental 16 forme interface entre les 

couches applicatives (non representees) et les couches inferieures, CC1 et 
CC2. La fonction principale devolue a cette couche 1 6 est une fonction de 
multiplexage/demultiplexage. 

Les communications avec la carte a puce 2a s'effectuent selon un 

30 paradigme similaire a celui utilise pour la manipulation de fichiers dans un 
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systeme Sexploitation du type "UNIX" (marque deposee) : OUVRIR 
("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation 
similairera~savoirla"presen 
5 (couche physique) et CCa2 (couche de lien de donnees), ainsi qu'une 
couche d'interface 26a, tout a fait similaire a la couche 16. 

Selon une_premiere caracteristique deJInyentjpn, on_p/eyoit, de part 

et d'autre, c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux 
couches de protocoles specif iques : 13 et 23a, respectivement. 
10 Dans le terminal 1, la couche specif ique 13 s'interface aux "drivers 

couches basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et 
aux couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
specif ique 13 permet le transfert de paquets reseaux de et vers la carte a 
15 puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10, le courrier electronique, etc., pour des utilisations mettant en 
oeuvre la carte a puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a 
fait similaire constitute par une instance supplemental de la couche 
20 specif ique, referencee 23a, pendant de la couche 13. 

De fagon plus precise, les couches specif iques, 13 et 23a, sont 
subdivisees en trois elements logiciels principaux : 

un module, 130 ou 230a, de transfert de blocs deformations 
entre les couches 13 et 23a, via les couches conventionnelles CCt, CC2, 
25 CCai et CCa2 ; 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 
132 ou 232a, qui realisent, par exemple, des fonctions de conversion de 
protocoles ; 
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et un module de gestion de la configuration specif ique, 131 et 
231a, respectivement ; module qui peut etre assimile a un agent intelligent 
particulier. 

PouT Amplifier, on appellera ci-apres les agents intelligentsT 
5 "agents", comme il a ete precedemment indique. 

On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 

PfQtocoJaire de communication entre Jes deux entites^ 

Les couches de niveau deux (couches de lien de donnees), CC2 et 
CCa2, assurent I'echange entre la carte a puce 2a et le terminal 1. Ces 
10 couches sont responsables de la detection et I'eventuelle correction 
d'erreurs de transmission. Differents protocoles sont utilisables, et a titre 
d'exemptes non exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere 

15 T=0; 

le protocole defini par la norme ISO 7816-3, en mode bloc T=1 

» 

ou le protocole defini par la norme ISO 3309, en mode trame 
"HDLC" (pour "High-Level Data Link Control procedure" ou procedure de 
20 commande de liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole 
ISO 7816-3, en mode bloc. 

De fagon connue en soi, a chaque couche de protocole, il est 
associe un certain nombre de primitives qui permettent les echanges de 
25 donnees entre couches de meme niveau et d'une couche a I'autre. A titre 
d'exemple, les primitives associees a la couche de niveau deux sont du type 
"demande de donnees" {"Data.requesr) et "envoi de donnees" par la carte 
("Data.response"), ainsi que "confirmation de donnees" ("Data.confirm"), etc. 
De fagon plus specif ique, les couches 13 et 23a sont chargees du 
30 dialogue entre la carte a puce 2a et I'hote, e'est-a-dire le terminal 1 . Ces 
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couches permettent lechange conformations entre un utilisateur (non 
represente) du terminal 1 et la carte a puce 2a, par exemple via des menus 
deroulants sous la forme d'hypertexte au format "HTML". Elles permettent 
aussi-la-mise-en-plaGe-d ! une-eonfiguration-adaptee-pour-l ? 6mission et/ou~la 
5 reception de paquets de donnees. 

Comme it a ete indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere couche, 130 ou 230a, est essentiellement constitute 
par un multiplexeur logiciel. Elle permet I'echange d'informations entre la 
10 carte a puce 2a et le terminal hote 1 , sous la forme d'unites de donnees de 
protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau deux 
(couche de liens de donnees). Ce protocole particulier de communication 
permet de mettre en communications au moins une paire d* "agents". Le 
15 premier agent de chaque paire, 132, est situe dans la couche 13, cote 
terminal 1 , le second, 232a, est situe dans la couche 23a, cote carte a puce 
2a. Une liaison entre deux "agents" est associee a une session, que Ton 
pourra appeler "S-Agent". Une session est un echange de donnees 
bidirectionnel entre ces deux agents. Si Tune ou Pautre des couches, 13 et 
20 23a, comporte plusieurs agents, les agents d'une meme couche peuvent 
aussi etablir de sessions entre eux et/ou avec les modules 131 et 231a, qui 
constituent des agents particuliers. 

De fagon plus precise, un agent est une entite logicielle autonome 
qui peut realiser tout ou partie de fonctions des couches de niveau trois et 
25 quatre, en fonction de la configuration mise en oeuvre par le terminal 1 . 

Les agents sont associes a des proprietes ou attributs particuliers. 
Pour fixer les id6es, et a titre d'exemple non limitatif, les six proprietes 
suivantes sont associees aux agents : 

"hote" : agent localise dans le terminal ; 
30 - "carte" : agent localise dans la carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 
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"reseau" : agent communiquant avec le reseau (cote terminal) ; 
"client" : agent qui initialise une session ; 
"serveur" : agent qui regoit une demande de session. 
Un _ agent part iculier esMdentifie par une-reference, parexemple un 
5 nombre entier de 16 bits (c'est-a-dire compris entre 0 et 65535). Le bit de 
poids fort (b15 = 1) indique si la reference est locale (communications 
locales a la carte a puce ou au terminal) ou distante (b15 = 0). 

II existe deux grandes categories d'agents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
10 "client", qui sont identifies par une reference variable, que Ton peut qualifier 
d'ephemere, delivree par le module de gestion de configuration, 131 ou 
231a. 

Les agents communiquent entre eux a I'aide d'entite dites "unites de 
donnee de protocole" ou "pdu" (pour "protocol data unit", selon la 
15 terminologie anglo-saxonne) constituant une reference de destination et une 
reference de source. On pourrait egalement appeler cette "pdu" particuliere 
"SmartTP pdu", en reference au terme anglais "Smart Card" (carte a puce) 
couramment utilise. Les "pdu" utilisent notamment les references definies ci- 
dessus. 

20 Une "SmartTP pdu", ou plus simplement "pdu" ci-apres, comporte 

une reference source, une reference de destination, un ensemble de bits 
constituant des drapeaux ou "flags" qui precisent la nature de la "pdu", et 
des donnees optionnelles : 

- le drapeau "OPEN" (ouvert) est positionne pour indiquer I'ouverture 
25 d'une session ; 

- le drapeau "CLOSE" (ferme) indique la fermeture d'une session ; et 

- Le drapeau "BLOCK" (verrouille) indique que I'agent est en attente tfune 
reponse de son correspondant et suspend toute activite. 

On appellera jeton une "pdu" qui ne comporte pas de donnees. 
30 L'entite "SmartTP" controle I'existence de I'agent destinataire et 

realise la commutation d'un paquet vers ce dernier. 



WO 01/59563 



PCT/FROI/00393 



19 

line session agent "S-Agent" possede trois etats remarquables, a 

savoir : 

- un etat deconnecte : aucune session n'est ouverte avec un autre agent 
^unetat-connecte-i-une-session-estouverte-avec-un-autre-agent-une 

5 session "S-Agent" etant identifiee par une paire de references ; et 

- un etat bloque, Pagent etant connecte et attendant une reponse de son 
correspondant. 

Le mecanisme d'etablissement d'une session "S-Agent" est le 

suivant : 

10 - une nouvelle instance d'un agent client est creee (cote carte a puce ou 
terminal), cet agent etant identifie par une reference ephemere pseudo- 
unique ; 

- Pagent client emet une "pdu n a destination d'un agent serveur (dont la 
reference est connue par ailleurs) avec le drapeau "OPEN" positionne et 

15 Pagent client passe a Petat connecte ou bloque selon la valeur du drapeau 
"BLOCK" ; et 

- Pagent serveur regoit la "pdu" avec le drapeau "OPEN" et passe a Petat 
connecte 

Une fois une session ouverte, deux agents echangent des donnees 
20 via des "pdu". 

Le mecanisme de fermeture d'une session est le suivant : 

- un agent emet une "pdu" avec le drapeau "CLOSE" positionne (et 
qui comporte eventuellement des donnees ; et 

- Pautre agent regoit une "pdu" avec le drapeau "CLOSE' positionne 
25 (et qui comporte eventuellement des donnees) et la session "S-Agent" passe 

a Petat deconnecte. 

La figure 3 illustre de fagon schematique le diagramme d'etats des 
sessions "S-Agent", telles qu'elles viennent d'etre rappelees. 

Les couches 130 et 230a gerent des tables (non representees) qui 
30 contiennent la liste des agents presents, cote terminal hote 1 et carte a 
puce 2a. 
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De fagon pratique, les agents permettent d'echanger des donnees 
(de I'hypertexte, par exemple), mais egalement de declencher des 
transactions reseau, autorisant des communications entre ia carte a puce 2a 
et un serveuF Sloigne 4 (figure 2). , 
5 Les modules de gestion de configuration, 131 et231a, 

respectivement, sont assimilables a des agents particuliers. Par exemple, le 
_ module .1 31, coteJerminaLhote l,_gere_notarnnnent d_es informations relatives 
a la configuration de ce terminal (modes de fonctionnement), liste des autres 
agents presents, etc. Le module 231a, cote carte a puce 2a, a des fonctions 
10 analogues. Ces deux agents peuvent etre mis en communication Tun avec 
Tautre pour etablir une session. 

De fagon pratique, la carte a puce 2a est avantageusement 
"adressee" par utilisation d'une adresse "URL" (pour "Universal Resource 
Locator") definissant un rebouclage sur le terminal 1 lui-meme, et non un 
15 pointage sur un serveur externe. A titre d'exemple, la structure de cette 
"URL" est habituellement la suivante : 

http://1 27.0.0.1:8080 (1), 
dans laquelle 127.0.0.1 est I'adresse "IP" de rebouclage et 8080 est le 
numero de port. 

20 La figure 4 illustre de fagon simplifiee Tarchitecture logique d'un 

systeme selon I'invention du type represents sur la figure 2, mais represents 
de fagon plus detaillee. La carte a puce 2a comprend plusieurs agents, dont 
deux seulement ont ete representees : un agent de type non precisement 
defini 232ai et un agent 232a2, de type dit "WEB". La pile logique 

25 comprend, les couches de protocole inferieures, referencees 200a, 
repondant aux normes ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire 
de commandes "APDU" 201ai, et le multiplexeur de paquets230a, ce 
dernier etant interface aux agents, notamment I'agent "WEB" 231a2. 

Du cote terminal, il existe deux piles, Tune communiquant avec le 

30 reseau Internet f?/, I'autre avec la carte a puce 2a. La premiere pile 
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comprend les organes 11 (figure 2 : Ci et C2) d'acces au reseau (normes 
OSI 1 et 2) et les couches de protocole "TCP/IP" (figure 2 : C3 et C4), 
referencees 1 00. Ces dernieres couches sont interfacees avec le navigateur 
"WEB" - TO^L'aDtre^pile comprend~les cc^ch^llenpfotocore - inf&rieures, 
5 referencees 101 , repondant aux normes ISO 7816-3 (figure 2 : C1 et C2K le 
gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce 

dernjer etant intejlace avec des agents, Jont un seuM32, est repLese.nte. Ce_ 

dernier, que Ton supposera de "type reseau", peut en outre communiquer, 
d'une part avec le navigateur 10, via les couches TCP/IP" 101, d'autre part 

10 avec le reseau Internet Rl, via ces memes couches "TCP/IP" 101 et I'organe 
1 1 , d'acces au reseau RL 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec 
une ou plusieurs couches de niveau applications, que Ton appellera 
simplement applications. Ces applications, A u A„ A n , sont, comme il a 

15 ete indique, des applications de type conventionnel. 

En resume, la fonction client/serveur "WEB", fournie par la carte a 
puce 2a, peut etre realisee par Tassociation de Tagent "WEB" 232ai dans la 
carte a puce et de Tagent reseau 132 dans le terminal 1, et par la mise en 
oeuvre de sessions entre agents, comme il a ete decrit. 

20 La carte a puce 2a presente done bien la fonctionnalite 

client/serveur "WEB". En outre, selon une caracteristique du procede de 
Tinvention, n'importe quelle application conventionnelle, A-\ a A n , du type 
"CGA" precite, peut etre activee au travers de ce client/serveur "WEB", soit 
par le navigateur "WEB" 10 present dans le terminal 1 , soit par un navigateur 

25 eloigne 4, localise en un point quelconque du reseau Internet /?/, par la mise 
en oeuvre de sessions entre agents. Selon le procede de I'invention, les 
applications, A-\ a An, ne necessitent pas d'etre re-ecrites et sont mises en 
oeuvre telles quelles. 

Dans le cadre de I'invention, tout ou partie des applications >4i a A n 

30 peut etre constitute par des "applets", chargees initialement dans une 
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memoire non volatile de la carte a puce 2 ou, au contraire, chargees par 
I'intermediaire des deux programmes de chargement OL et IL, dont on 
precisera ci-apres la nature et les lieux de stockage possible. 

SelorL un-autre-aspeet-de l ! invention7^la~f onction "seTveur ^WEB^ 

5 offerte par la carte a puce inclut un mecanisme similaire a la tonction dite 
"CGI" (pour "Common Gateway Interface" ou "interface de passerelle") 
implantee dans les serveurs "WEB" classique. 

Avant de decrire un exemple d'architecture conforme a 1'invention, 
permettant de realiser une fonction de ce type, au sein meme de la carte a 
10 puce, il est utile de rappeler les principals caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en oeuvre, depuis un serveur 
"WEB", duplications ecrites pour les systemes d'exploitation "UNIX" 
(marque deposee), "DOS", ou "WINDOWS" (marque deposee). A titre 
15 d'exemple, pour le systeme d'exploitation "UNIX", la specification est 
"CGI 1.1" et pour le systeme d'exploitation "WINDOWS 95", la specification 
est "CGI 1.3". 

Toujours a titre d'exemple, une requete "HTTP" pour une adresse 
"URL", du type : 

20 "http://www.host.com/cgi-bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), 
est interpretee par un serveur "WEB" comme I'execution d'un script de 
commande, de type "CGI" nomme "xxx" et present dans le repertoire "cgi- 
bin" de ce systeme hote. Bien que le nom du repertoire puisse etre a priori 

25 quelconque, par convention, c'est le nom donne au repertoire stockant les 
scripts de type "CGI". Un script est une suite destructions du systeme 
d'exploitation du systeme hote dont le resultat final est transmis au 
navigateur "WEB" emetteur de la requete precitee. Differents langages 
peuvent etre utilises pour ecrire ce script, par exemple le langage "PERL" 

30 (marque deposee). 
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De fagon pratique, la requete est habituellement affichee sur un 
ecran informatique sous la forme d'un formulaire compris dans une page 
"HTLM". Le langage "HTLM" permet de traduire un formulaire en une 
adresse "URL". L e formulaire_comp,Qrte,un-Ou plusieurs-champs.-obliqatoires- 
5 ou non, qui sont remplis par un utilisateur a I'aide des moyens de saisie 
habituels : clavier pour le texte, souris pour les cases a cocher ou les 
boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'eventuellement 
"des informations et Instructions Elites "cachees") est emis a destination du 
serveur "WEB". Le code "HTLM" de la page decrit la structure materielle du 
10 formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la 
structure des champs de donhees a saisir (nom, longueur, type de donnees, 
etc.). 

La transmission peut s'effectuer selon deux types de formats 
principaux. Un premier format utilise la methode dite "POST" et un second la 
15 methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une 
carte a puce, meme si celle-ci off re la fonctionnalite client/serveur "WEB" 
conformement a Tune des caracteristiques de Tinvention. 
20 On va maintenant decrire un exemple d'architecture permettant 

d'activer une application quelconque, de type conventionnel, via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Parmi les agents intelligents, conforme a Tun des aspects de 
Tinvention, on prevoit des agents intelligents particuliers, que Ton appellera 
25 ci-apres "Agents traducteurs de script" ou de fagon abregee "ATS". Le script 
est alors interprets par un des agents intelligents. Cette traduction peut etre 
realisee de differentes manieres : 

a/ par I'agent "WEB" 232ai lui-meme, qui est dote dans ce cas d'une 
double capacite ; 
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b/ par un agent script unique capable de traduire Tensemble des scripts 
presents dans la carte a puce 2a ; 

c/ par un agent de script dedie que Ton appellera "ATSD" ci-apres (un 

_ __^_agent par_script)-; ou 

5 d/ par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, 
qui est dote, dans ce cas, d'une double capacite. 

Uagent "APDU M 2010a est une composante_de ]a__cojJche 
"gestionnaire d'ordres "APDU" 201a. Cette derniere est une couche capable 
de centraiiser tous les ordres "APDU" emis et/ou regus par le systeme, de 
10 selectionner des applications, parmi A A a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon Tune des 
caracteristiques de I'invention de communiquer avec tous les agents 
intelligents (via des sessions), que ces agents soient localises dans 
v i'enceinte 6 ou la carte a puce 2a. 
15 Dans le cas c/ ci-dessus, une session est ouverte entre I'agent 

M WEB" 232ai et Tun des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les 
agents traducteurs sont du type "ATSD". lis sont references ATS^ a ATS n et 
associes aux applications >A 1 a A n . ^application selectionnee etant supposee 
20 etre Tapplication A, la session s'etablit entre I'agent "WEB" 232ai et I'agent 
ATS.. 

Un agent traducteur de script genere une suite d'ordres "APDU". 
Une session est ouverte entre I'agent traducteur, par exemple I'agent ATS r 
et I'agent "APDU" 2101a. Les ordres sont alors emis vers I'agent 
25 "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a selectionne 
Implication "CGA" A. et lui transmet les ordres "APDU", ordres traduits et 
done conventionnels, qu'elie est en mesure de comprendre. Cette 
application est done correctement activee, sans avoir a la modifier ou a la 
reecrire. 
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Les reponses de Tapplication A. sont transmises au gestionnaire 
d'ordres "APDU" 210a, a I'agent "APDU" 2010a, puis de nouveau a I'agent 
ATS. (et de fagon plus generale a I'agent traducteur de script). 

L^^differents ^ ch^n^ements sont represents symboliquement sur 
5 la figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointilles 
a I'interieur de ces blocs. 

Leprpcede. selon IjnyentLon utilise_les.deux caracteristiques qui 
viennent d'etre rappelees : fonctionnement de la carte a puce en tant que 
serveur/client "WEB", incluant une fonction "cgi". Le chargement d'une 
w "applet" dans la carte a puce s'effectue en effet via I'interface "CGI" offerte 
par celle-ci. 

De fagon plus precise, selon une caracteristique de I'invention, la 
partie de programme de chargement IL, localisee dans la carte a puce 2a, 
est constitute par un script. II s'agit, par exemple, d'un script associe a 

15 Tapplication referencee A. sur la figure 5. Ce script est, selon une 
caracteristique du procede de invention, active par une requete "HTTP", les 
echanges entre la partie OL et la partie IL s'effectuant selon le protocole de 
communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a 
priori compatibles. En outre, il n'est plus necessaire que la proximite 

20 physique soit respectee, comme dans Tart connu (voir figure 1). La partie OL 
peut desormais etre localisee dans le terminal ou, de. preference, dans un 
serveur eloigne (les liaisons entre le serveur et le terminal s'effectuant 
suivant le protocole "TCP/IP"), voire, comme il le sera montre, etre stockee 
dans la carte a puce elle-meme. La requete "HTTP" precitee est initiee par la 

25 partie OL. 

II convient de remarquer que les donnees adressees a Pagent 
"WEB" 232ai sont transportees, de fagon conventionnelle en soi, sous 
formes d'ordres "APDU" destines a Tapplication particuliere constituee par le 
"Multiplexeur de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a 
30 selectionne cette application de maniere tout a fait similaire aux autres 
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applications de type "CGA", a>4 n , presentes dans la carte a puce 2a. En 
d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire 
d'ordres "APDU" 201a comme une application "CGA" ordinaire. 

— — ta-requete-"HTTP M -est^ 

5 detecte une reference a un repertoire particulier, que Ton appellera ci-apres 
par convention "cgi-smart" (par analogie a "cgi-bin"), d'une part, et a une 
application particuliere, IL _dans le cas de I'exemple decriL Le chemin 
complet est done, en I'occurrence "cgi-smart/il". 

Selon une caracteristique du procede de invention, I'entite T ci- 
10 dessus designe un script particulier associe une application egalement 
particuliere (IL en I'occurrence). 

Une session est ouverte entre I'agent traducteur, par exemple 
I'agent ATS U et I'agent "APDU" 2010a. L'agent traducteur de script ATS\ 
genere une suite d'ordres "APDU". Les ordres sont emis vers I'agent 
15 "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a selectionne 
Tapplication "CGAM/ (par exemple I'application IL) et lui transmet les ordres 
"APDU", ordres traduits et done conventionnels, qu'elle est en mesure de 
comprendre. Cette application est done correctement activee. 

La reponse de ['application IL (Aj) est transmise en sens inverse au 
20 gestionnaire d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de 
nouveau a I'agent ATSj (et de tagon plus generate a I'agent traducteur de 
script). 

La reponse, constitute par un tormulaire en langage "HTLM" 
reprend le chemin inverse, par la mise en oeuvre de sessions entre agents 
25 intelligents apparies, pour etre re-transmise au terminal 1 et, eventuellement 
a un serveur eloigne 4 (figure 4), via le reseau Internet Rl, pour atteindre 
finalement Tapplication OL. 

La figure 6 illustre schematiquement I'architecture logique 
permettant le chargement d'une "applet" selon le procede de ['invention. On 
30 retrouve sur ce schema les blocs materiels constitues par le terminal 1 , le 
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lecteur de carte a puce 3 et la carte a puce 2a, communiquant par mise en 
oeuvre du protocole normalise ISO 7816 precite et Techange d'ordres 
"APDU", de maniere classique en soi. La partie OL est mise en relation avec 
— — la-partie-lt(sous-forme-d r un-script-referenceits)7par des"eclWgesTeloh'le" 
5 protocole Internet "TCP/IP", de la maniere decrite precedemment, par mise 
en oeuvre des ionctions serveur "HTTP" (reference SC) et "CGI" de la carte a 

puce 2a. 

On doit bien comprendre que, bien que represents a I'exterieur de 
la carte a puce 2a pour des raisons de commodite, les blocs SC et ILs sont 
10 constitues par differents modules internes de celle-ci, qui ont ete decrits par 
reference a la figure 5. 

Par contre, le programme OL n'est pas obligatoirement stocke dans 
le terminal 1 . 

On va maintenant detainer un premier exemple de chargement 
15 d'une "applet" dans une carte a puce 2a, par mise en ceuvre de la methode 
dite "GET". 

On suppose que le fichier de chargement de I" "applet", reference 7, 
presente la structure illustree par la figure 7 : une entete 70, un corps 
principal 71 constitue par du "Byte Code" en langage "JAVA" et une 
20 signature electronique 72. L'entete represente un identifiant d'une application 
particuliere, generalement appele "Application Identifier" ou simplement 
"AID". La signature electronique 72 est un mot chiffre avec une cle publique 
ou privee, obtenu a partir du code 71. L'ensemble du fichier 7 peut 
egalement etre chiffre, pour des raisons de confidentialite, lorsqu'il s'agit 
25 d'applications dites sensibles. Optionnellement, on peut prevoir une ou 
plusieurs signature(s) electronique(s) supplementaire(s) non representee(s). 

Les principals etapes du processus sont illustrees 
schematiquement par la figure 8. 

Pendant une premiere etape, la partie de programme de 
30 chargement OL recupere, par une commande de type "GET", un formulaire 
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de chargement a partir de la carte a puce 2a, formulaire en langage "HTML" 
que Ton appellera arbitrairement "download.html". 

Cette recuperation est effectuee en consultant une page 

correspondante-dont l-URL-esUypiquement-de la-forme suivante-: 

5 http://1 27.0.0.1 :8080/download.html (3), 

dans laquelle http://1 27.0.0.1:8080 est I'adresse URL de rebouclage 
proprement dite, telle quelle a ete definie par la relation (1), et 
"dbwnload.htmr la page "HTML" a obtenir. Cette requete met en oeuvre une 
session entre agents intelligents comme il a ete decrit en regard des figures 
w 2 a. 4, selon un premier aspect de I'invention. La carte a puce 2a joue alors le 
role d'un serveur "WEB\ 

La carte a puce 2a envoie le formulaire "download. html" lors d'une 
deuxieme etape, toujours par ouvertures de sessions entre agents 
intelligents apparies, selon le procede de I'invention. Le formulaire obtenu 
15 peut etre affiche sur un ecran 5 par I'intermediaire du navigateur 10. 

Pour fixer les idees, un exemple d'un tel formulaire 8 est illustre par 
la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le 
formulaire comprend des zones d'affichage pour I'entete 70 du fichier de 
chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 
20 est du type dit "TEXTAREA" en langage "HTML" et presente une facilite dite 
d' "ascenseur" pour I'affichage deroulant de textes longs. Les informations 
correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement 
arbitraires. Enfin, on prevoit, de fagon classique en soi, un bouton d'envoi 
"send", reference 81, et un bouton de remise a zero "reset", reference 82. 
25 Ces boutons sont a la disposition d'un utilisateur du terminal (non 
represente). Le bouton d'envoi 81 permet de valider le formulaire et le 
retransmet a la carte a puce 2a ("soumettre le fichier de chargement" sur la 
figure 8) et le bouton de remise a zero 82 permet d'effacer les informations 
affichees et de re-initialiser le formulaire. 
30 Le code "HTML" necessaire pour programmer un tel formulaire est 

bien connu en soi et est a la portee de Thomme de metier. II n'est pas 
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necessaire de le detaitlor de nouveau. On peut cependant indiquer qu'il 
contient notamment une ligne de code en langage "HTML" qui se presente 
typiquement sous la forme : 

<form action="http://1 27.0.01 :8080/^i^m^rt/joader> (4), 

5 dans laquelle http://1 27.0.01:8080 est I'URL de rebouclage de la relation (1), 
cgi-smart le repertoire "CGI" precite contenant le script de chargement 
"loader" que Ton a appele "il", script associe a la partie IL du programme de 

chargement. - - — — - 

Si Taffichage visuel du tormulaire 8 sur I'ecran 5 n'est pas souhaite 
10 (par exempie s'il n'y a pas d'operateur humain, les informations peuvent etre 
cachees incorporant le parametre "HTML" suivant : "TYPE=hidden" dans la 
ligne de code (4) precitee. 

Lors d'une troisieme etape, la partie OL envoie une requete "HTTP" 
de type "GET" a la carte a puce 2a, toujours par ouverture de sessions entre 
15 des agents intelligents apparies. En faisant appel a la fonction "CGI" offerte 
par la carte a puce 2a, telle qu'elle a ete decrite en regard de la figure 5, 
I'application IL s'execute, le serveur "WEB" forme par la carte a puce 2a 
passant les parametres de la requete "HTTP" a cette derniere application. 

La requete precitee contient une ligne de code typiquement de la 
20 forme suivante : 

Smart/loader?AID=xxx&ByteCode=yyy&Signature=zzz (5), 
Dans laquelle "xxx" est I'entete 70 ("2001" dans I'exemple de la 
figure 9), "yyy" est le "Byte Code" 71 ("0123456789ABCDEF" dans I'exemple 
de la figure 9) et "zzz" la signature electronique 71 ("0123456789ABCDEF" 
25 dans I'exemple de la figure 9). Les trois parties du fichier de chargement sont 
done bien inserees dans trois champs du formulaire "HTML" 8, sous forme 
concatenee. 

Le chargement d'une "applet" particuliere identifiee par Tentete 70 a 
lieu a ce moment. 

30 Enfin, lors d'une quatrieme etape un code de retour est transmis de 

la partie IL a la partie OL, toujours par mise en ceuvre de sessions entre 
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■„ „ s'aqU en general tfun simple acquittement ou. si 

zzrr:^^— r - r r - Dans ce 

„. .. lormulaire _ _ 

80 , une zone a* aoe e e* » ^ g , „ de 

signalure ^ - ; meots iouent un r61e , oul , m similaire 

remise a zero Reset 82. ^ de ^ re . 

, aux elements ae memos re.renc - * ^ 
decrire. Par centre, la zone d afl.chage ^ _ ^ ( , 



("APPLET.BIN"). bj connue en 

La r^hode "POST- comma ,a ^ GET ^ 
20 soi, a, . es, inu,a de la re-deenre en de * Dans ^ 
,, nv en,io, r "appler correspondent au cd,e APPLET . 
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Par exemple, apres analyse du fichier de chargement, la partie IL 
peut demander une autorisation (c'est-a-dire une signature electronique) 
supplementaire, par exemple celle d'une instance gouvernementale. Elle 
renwi^lors^ 
5 "HTML" suivante (6) : 



<TITLE>AuthoiisaLion form </J|TLE> „ „ 

<FORM ACTION="http://@carte:8080/cgi-smart/loader ,, > 
<INPUT TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature 
</FORM> 

dans laquelle "Authorisation form", entre les balises "HTLM" denommees 
"<TITLE>" et </TITLE>, represente le titre (arbitraire) du formulaire, "@carte M 
la traduction litterale de Tadresse URL de rebouclage de la relation (1) et 
15 8080 le numero de port, la ligne de code : 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature 
(7) 

requiert I'entree d'une variable appelee arbitrairement "Signature", en mode 

texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" 
20 indiquant la fin du code de formulaire. 

Le processus complet comprend alors deux etapes supplementaires 

avant Tetape finale d'acquittement ou de code d'erreur, soit six etapes, 

comme illustre par la figure 1 1 . 

De fagon plus generale, le nombre d'allers et retours peut dependre 
25 de parametres figurant dans Tun ou Tautre des formulaires echanges entre la 

carte a puce et la partie OL des programmes de chargement. 

Jusqu'a ce point, la localisation de la partie OL n'a pas ete precisee 

expressement. Outre le fait que le procede rend, a priori, compatible OL et 

IL, il permet aussi une tres grande souplesse precisement quant a cette 
30 localisation, etant entendu que la partie IL est stockee dans la carte a puce 

2a comme formant Tune des applications presente dans cette carte a puce. 

Le procede selon ^invention presente notamment Tavantage supplementaire 
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de ne plus exiger une proximite physique entre les deux parties OL et IL, 

puisqu'elles ne sont plus tributaires du protocole de communication ISO 

7816, les echanges entre ces deux portions de logiciel mettant en ceuvre le 

pfotocole^de commTmirati^lffiernet TCP/IP: 
5 Aussi, la partie OL, ainsi que les donnees proprement dites de 

r "applet" a charger sur la carte a puce 2a peuvent etre stockees soit en 
local,j>qi^dans un site eloigne. Dans tous les cas cependant, les echanges 

entre ces deux parties mettent en oeuvre, comme il vient d'etre rappele, un 

protocole de communication "TCP/IP" et le chargement d'une "applet" se 
w deroule comme ii a ete rappele precedemment grace aux fonctions de 

serveur/client "WEB" et "CGI" offertes par la carte a puce 2a. 

On va decrire maintenant, par reference aux figures 12A a 12G, les 

principals architectures pouvant etre mises en oeuvre dans le cadre de 

I'invention. 

15 La figure 12 A illustre une architecture de systeme selon laquelle la 

partie OL est stockee en local sur le terminal 1. Celui-ci est connecte a un 
serveur eloigne 4, via le reseau Internet RL Les donnees de I' "applet" a 
charger dans la carte a puce 2a, referencees Da, sont stockees sur ce 
serveur 4. Une requete "HTTP" permet de les transferer vers la carte a puce 

20 2a, via le terminal 1 (et un lecteur de carte a puce non represents), par mise 
en oeuvre du protocole de communication Internet "TCP/IP". 

Dans ('architecture de systeme representee sur la figure 12B, la 
partie de programme de chargement OL et les donnees Da sont stockees 
localement dans le terminal 1. La connexion du terminal 1 au reseau Internet 

25 Rl est optionnelle. Pour le moins, elle n'est pas requise pour le chargement 
d'une "applet" selon les etapes du procede de invention. Cette connexion a 
ete representee en traits pointilles. Le terminal peut done etre autonome. 

Dans ('architecture de systeme representee sur la figure 12C, la 
partie de programme de chargement OL et les donnees Da sont stockees 

30 dans un serveur distant 4. Les communications entre le serveur 4 et la carte 
a puce 2a, via le reseau Internet Rl, le terminal 1 et le lecteur de carte a 
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puce (non represente) s'effectue par des requetes "HTTP", et mise en oeuvre 
du protocole TCP/IP". 

L'architecture de systeme representee sur la figure 12D est simiiaire 
a~ceire~de~Ia~figure~T2CrL^^ 
5 de chargement OL est stockee dans un premier serveur distant, reference 
4a, et que les donnees Da, sont stockees dans un second serveur distant, 
reference 4b. 

Dans ['architecture de la figure 12E, la partie du programme de 
chargement, referencee ici OL\ est constitute par un composant du 
10 navigateur 10 lui-meme. II s'agit avantageusement d'une "applet" integree 
dans ce navigateur. Le type d'entree a utiliser dans ce cas est "file" (fichier). 

De fagon avantageuse egalement, les donnees Da, de P "applet" a 
charger sur la carte a puce 2a, peuvent etre stockees sur un support 
d'enregistrement de donnees externe 9, par exemple une disquette comme 
15 illustre par la figure 12E. Natureilement d'autres supports sont utilisables : 
CedeROM, bande magnetique, etc. 

Si on utilise la methode "POST" precitee, il suffit de specifier la lettre 

de Tunite de stockage, par exemple "A" pour la disquette 9, un eventuel 

> 

chemin (repertoire, sous-repertoires) et le nom du fichier a charger. Pour 
20 fixer les idees, le chemin complet pourrait etre typiquement : 

A:\APPLET.BIN (8) 
Du fait de la fonction serveur/client "WEB" offerte par la carte a 
puce 2a, selon une des caracteristiques du procede de I'invention, le 
, navigateur 1 0 est a meme, contrairement a Tart connu, de communiquer 
25 directement avec cette derniere, comme il Ta ete montre en regard des 
figures 2 a 4. Les communications s'effectuent par Touverture de sessions 
entre agents apparies. 

L'architecture de systeme illustree par la figure 12F est une variante 
de ('architecture de la figure 12E. Selon cette variante, la partie de 
30 programme de chargement OL est stockee dans la carte a puce 2a elle- 
meme, sous forme d'une "applet" eri langage "JAVA". Par une requete 
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"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Une fois la partie OL chargee, les 

etapes-ulterieures-sont "communes~au-cas~precedent:~tes~donnees Da 

5 peuvent egalement etre stockees sur un support externe, par exemple une 
disquette 8. 

^architecture de systeme de la figure 12G est une variante de celle 
de la figure 12F. La seule difference est que la partie de programme de 
chargement OL est stockee sur un serveur eloigne 4, sous forme d'une 
w "applet" en langage "JAVA". Comme precedemment, par une requete 
"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Les autres etapes sont communes 
au cas precedent. 

15 II est clair que d'autres variantes d'architecture peuvent etre mises 

en oeuvre sans sortir du cadre de ['invention. II est notamment possible de 
charger les donnees Da dans le terminal 1 a partir de diverses sources : par 
exemple a partir d'un autre systeme informatique, connecte au terminal 1 par 
un reseau local ou par tous autres moyens telematiques. 

20 A la lecture de ce qui precede, on constate aisement que Tinvention 

atteint bien les buts qu'elle s'est fixes. 

La mise en oeuvre du chargement d'une "applet" dans une carte a 
puce par interface "CGI" d'un serveur "WEB" loge dans cette carte a puce 
presente notamment les avantages suivants : 

25 L'utilisation de formulaires en langage "HTML" standardise le 

chargement et rend les parties de programmes de chargement OL et IL a 
priori compatibles. En effet, comme il a ete montre, c'est la partie IL situee 
dans la carte a puce qui decrit, dans les champs du ou des formulaire(s) 
renvoye(s), le parametrage de chargement auquel il s'attend. 
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Par ailleurs, ce mecanisme de communication entre les parties de 
programme de chargement OL et IL permet de gerer simplement des 
sequences d'echanges dynamiques lors du chargement. 

t'utilisatioTrde^^^ 

5 echanges entre les parties de programme de chargement OL et IL permet de 
les separer physiquement. Seul un routage de paquets "IP" est necessaire 
sur le te^minal^Le chargemen^peul : alors se faire dans urLlecteur carte_a_ 
puce banalise, puisque Ton conserve le protocole de communication ISO 
7816. Le terminal peut etre un simple micro-ordinateur standard connecte a 
10 Internet. 

Selon un aspect avantageux egalement du procede de I'invention, 
les applications stockees dans la carte a puce restent standards, et done 
n'ont pas a etre re-ecrites. La carte a puce et le terminal eux-memes ne 
necessitent que peu de modifications pour pouvoir accommoder le procede 
15 de ('invention : ces dernieres se resument a Timplantation, dans ces deux 
unites, d'une couche logicielle de protocole de communication qui a ete 
appelee specifique, couche logicielle incluant des agents intelligents. 

Alternativement, la partie de programme de chargement OL peut 
etre chargee dynamiquement sur le terminal, au travers la carte, a partir de 
20 celle-ci ou d'un serveur "HTTP" eloigne. 

Un simple navigateur Internet peut etre utilise comme programme 
de chargement OL. 

II doit etre clair cependant que invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
25 les figures 2 a 12G. 

D'autre part, en lieu et place du langage "HTML", d'autres langages 
similaires, adaptes aux protocoles de communication de type "Internet" 
peuvent etre utilises, notamment le langage "XML". 

L'invention concerne aussi un procede de chargement d'une piece 
30 de logiciel dans une carte a puce a partir d'un terminal connecte a ladite 
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carte a puce par I'intermediaire d'un lecteur de carte & puce permettant des 
communications selon un premier protocole determine, le terminal et la-carte 
a puce comprenant des moyens de traitement deformation et des moyens 

^_^cJ<age_d1nform - 

5 oeuvre et la cooperation de premier et second programmes de chargement, 
ledit second programme de chargement etant stocke dans les moyens de 
stockage d'information de ladite carte a puce, caracterise en ce qu'il 
comprendau moins Fes phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans les 
10 moyens de stockage d'information de ladite carte a puce (2a), une 

premiere piece de logiciel (23a), formant une couche protocolaire de 
communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans les 
moyens de stockage d'information dudit terminal (1), une seconde 
15 piece de logiciel (13), formant une couche protocolaire de 

communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant Tune 

20 avec i'autre, grace auxdits moyens de traitement d'information du terminal et 
de la carte a puce, de maniere a permettre I'etablissement d'une session 
d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) off re la 
fonctionnalite d'un client/serveur "WEB" ; 

25 en ce qu'il comprend une troisieme phase preliminaire consistant a 

implanter dans les moyens de stockage d'information de ladite carte a puce 
(2a) au moins une deuxieme entity logicielle (ATS } - ATS n ), apte a interpreter 
une suite destructions et a la traduire en une suite d'ordres, de maniere a 
cooperer avec ladite seconde piece de logiciel specifique (23a) pour que 

30 ladite carte a puce offre une fonctionnalite d'interface passerelle dite "CGI", 
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la dite carte a puce comprenant aii moins une desdites suites destructions 
associee au dit second programme de chargement (IL) ; 
et en ce quit comprend au moins les etapes suivantes : 

17 ouverture-d ! une-premiere-session d ! echanges-de-donnees 

5 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la transmission d'une requete pour que ledit premier 
programme de chargement (OL) recupere des donnees de 
parametrage de chargement fournies par ledit second programme de 
10 chargement (IL) ; 

21 ouverture d'une deuxieme session d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour transmettre lesdites donnees de parametrage de 
15 chargement au dit premier programme de chargement (OL), lesdites 

donnees de parametrage comportant une reference aux dites 
instructions associees au dit second programme de chargement (IL) ; 
et 

3/ ouverture d'une troisieme session d'echanges de donnees 
20 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la soumission d'un fichier de chargement (7) prenant en 
compte lesdites donnees de parametrage de chargement, ledit fichier 
comprenant des donnees (70, 71, 72) associees a ladite piece de 
25 logiciel a charger (Da) ; interpretation de ladite suite destructions 

associee au dit second programme de chargement (IL), par mise en 
ceuvre de ladite fonctionnalite "CGI", de maniere a generer une suite 
d'ordres transmise au dit second programme de chargement (IL), a 
executer ce programme (IL) et a obtenir ledit dechargement de ladite 
30 piece de logiciel (Da). 
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REVEND1CATIONS 



1. Procede de chargement d'une piece de logiciel dans une carte a puce a 
partir d'un terminal connecte a ladite carte a puce par I'intermediaire d'un 
5 lecteur de carte a puce permettant des communications selpn un premier, 
protocole determine, ledit chargement s'effectuant par la mise en ceuvre 
et la cooperation de premier et second programmes de chargement, ledit 
second programme de chargement etant stocke dans ladite carte a puce, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

10 aJ une premiere phase preliminaire consistant a implanter, dans 

ladite carte a puce (2a), une premiere piece de logiciel (23a), formant 
une couche protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal (1), une seconde piece de logiciel (13), formant une 
15 couche protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 
avec I'autre de maniere a permettre I'etablissement d'une session 
20 d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) offre la 
fonctionnalite d'un client/serveur "WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite 
25 logicielle (ATS, - ATS n ) t apte a interpreter une suite destructions et a la 
traduire en une suite d'ordres, de maniere a cooperer avec ladite seconde 
piece de logiciel specifique (23a) pour que ladite carte a puce offre une 
fonctionnalite d'interface passerelle dite "CGI", la dite carte a puce 
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comprenant aii moins une desdites suites destructions associee au dit 
second programme de chargement (IL) ; 

et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d r une premiere session d'echanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 

transmission d'une requete pour que ledit premier programme de 

ch^gement _ (OL)_ recupere _ cLes_donne„es_ de .parametrage de~ 

chargement fournies par ledit second programme de chargement (IL) ; 
21 ouverture d'une deuxieme session d'echanges de donnees 

10 entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

transmettre lesdites donnees de parametrage de chargement au dit 
premier programme de chargement (OL), lesdites donnees de 
parametrage comportant une reference aux dites instructions associees 
au dit second programme de chargement (IL) ; et 

15 3/ ouverture d'une troisieme session d'echanges de donnees 

entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 
soumission d'un fichier de chargement (7) prenant en compte lesdites 
donnees de parametrage de chargement, ledit fichier comprenant des 
donnees (70, 71, 72) associees a ladite piece de logiciel a charger 

20 (Da) ; interpretation de ladite suite destructions associee au dit second 

programme de chargement (IL), par mise en ceuvre de ladite 
fonctionnalite "CGI", de maniere a generer une suite d'ordres transmise 
au dit second programme de chargement (IL), a executer ce 
programme (IL) et a obtenir ledit dechargement de ladite piece de 

25 logiciel (Da). 

2. Procede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donnees 
selon ledit premier protocole determine, definies par la norme ISO 7816, 
30 chacune comprenant au moins des couches protocolaires de 
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permettre lesdits echanges de donnees entre ladite carte a puce (2a) et 
ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel specifique formant lesdites 

5 couches protocolaires de communication specifiques, respectivernent, et 
en ce que ces pieces de logiciel (13, 23a) comprennent chacune deux 

jentites suppjementaires constitutes jj'un dojnnees__ 

(130, 230a), formant interface avec lesdites couches basses (101, 200a) 
des premiere et deuxieme piles protocolaires, et d'un module de gestion 

10 (131, 231a), et en ce que lesdites premieres entiles de chaque paire sont 
constitutes de modules logiciels, dits agents intelligents (132, 232a1) 
etablissant lesdites sessions. 

3. Procede selon la revendication 2, caracterise en ce que ladite suite 
^instructions a interpreter associee au dit second programme (IL) de 

15 dechargement est constitute par un script et en ce que ladite deuxieme 
entite logicielle est constitute par un module logiciel dit agent intelligent 
traducteur de script (ATS t -ATS n ) fournissant des ordres comprthensibles 
par ledit second programme de chargement (OL). 

4. Proctdt selon la revendication 3, caracttrist en ce que ladite premiere 
20 ttape comprend Ttmission d'une requete de type dit "HTTP" selon un 

protocole de type Internet par adressage d'une page dtterminte en 
langage "HTML" contenant lesdites donntes de paramttrage, ladite 
adresse ttant une adresse de type "URL" de rebouclage sur ladite carte a 
puce (2a). 

25 5. Procede selon la revendication 4, caracttrist en ce que ladite deuxieme 
ttape comprend renvoi par ladite carte a puce (2a) d'un formulaire (8, 8') 
en langage "HTML" et en ce que ledit formulaire (8, 8 1 ) comprend au 
moins une adresse de type dit "URL" de rebouclage sur ladite carte a 
puce (2a) et un chemin menant a un rtpertoire determine contenant ledit 
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script associe au dit second programme de chargement (IL), de maniere a 
ce que ce dit premier programme de chargement (OL) recupere les dites 
donnees de parametrage. 

6- Procede selon la revendication 5, caracterise en ce que ladite troisieme 
5 etape comprend renvoi d'une requete de type dit "HTTP" a ladite adresse 
"URL", d6signant ledit repertoire contenant ledit script associe au dit 
second programme de chargement (IL), ladite requete comprenant 
lesdites donnees representant ladite piece de logiciel a charger (Da), 
interpretation dudit script et I'execution dudit second programme de 
w chargement (OL), de maniere a obtenir ledit chargement de la dite piece 
de logiciel (Da). 

7. Procede selon la revendication 6, caracterise en ce que ladite piece de 
logiciel (Da) est une appliquette ecrite en langage "JAVA" (marque 
deposee). 

15 8. Procede selon la revendication 7, caracterise en ce que ledit fichier de 
chargement (7) est incorpore dans ledit formulaire (8, 8*) et comprend une 
entete (70) identifiant ladite appliquette, des donnees (71) et au moins 
une signature electronique (72) obtenue a partir du chiffrement desdites 
donnees. 

20 9. Procede selon la revendication 8, caracterise en ce qu'il comprend au 
moins une premiere etape supplementaire, realisee apres ladite troisieme 
etape, et en ce que cette premiere etape supplementaire consiste en 
I'ouverture premiere session supplementaire d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

25 transmettre un code predetermine regu par ledit premier programme de 
chargement (OL). 
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10-Procede selon la revendication 9, caracteris6 en ce que ledit code 
predetermine consiste en un acquittement lorsque lesdites trois premieres 
Stapes se s ont deroulees correctement ou un code d'erreur dans le cas 
contraire. 

5 H.Procede selon la revendication 10, caracterise en ce qu'il comprend au 

moms deux etapes supplementaires,, realisees apres ladite troisieme 

etape, comprenant Touverture de sessions d'echanges de donnees 
bidirectionnels entre ladite carte a puce (2a) et au moins ledit terminal (1) 
pour la transmission d'un formulaire supplemental requerant la 
10 soumission de donnees supplementaires. 

12. Procede selon la revendication 11, caracterise en ce que lesdites 
donnees supplementaires comprennent une signature electronique 
supplemental. 

13. Procede selon la revendication 12, caracterise en ce que ledit terminal 
15 etant connecte a au moins un serveur eloigne (4) via un reseau de type 

Internet (/?/) et par la mise en oeuvre de protocole de communication de 
type Internet, un desdits agents intelligents (132) est associe a un attribut 
dit de "reseau" permettant des communications avec ledit reseau Internet 
(f?/) et en ce que ledit premier programme de chargement (OL) est stocke 
20 sur Tun desdits serveurs eloignes (4, 4a). 

14. Procede selon la revendication 13, caracterise en ce que, ledit terminal 
(1) comprenant un navigateur de type "WEB" (10), ledit premier 
programme de chargement (OL') est constitue par un composant logiciel 
dudit navigateur "WEB" (10). 

25 15-Procede selon la revendication 14, caracterise en ce que ledit composant 
logiciel (OL") est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans ladite 
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carte a puce (2a), ledit chargement etant obtenu par remission d'une 
requete de type "HTTP", avec un adressage de type "URL" de ladite carte 
a puce (2a). 

16.Procede selon la revendication 17, caracterise en ce que ledit composant 
5 logiciel (OL n ) est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans un 
desdits serveurs eloignes (4), ledit chargement etant obtenu par remission 
d'une requete de type "HTTP", avec un adressage de type "URL" dudit 
serveur eloigne (4). 
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ou la theorie const rtu ant la base de r invent ion 

*X" document particulieremerit pertinent, finven t»n revendiquee ne peut 
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